Hi Kirgman.

Thank you so much for your reply. I apologize if my comment was too demanding or critical. Since you asked for my opinion, I didn't hold back.

Please excuse my frankness and any lack of tact.

In any case, every engine has its advantages, and it's clear that no one can be the best in every aspect. Or at least, it's extremely difficult and requires intensive work.

Your work is incredible, and above all, your active listening to the user community is second to none.

You have my full support.

Beautiful material and exceptional image quality.

Hello again, Kirgman.

Thanks for your reply.

Assuming Centileo is in Beta, there are some aspects I wish were different.

- First, the default material values.

When creating a new material, it starts with a very high reflection and refraction index (from my point of view) and a very pronounced specular effect. This makes everything excessively reflective, and sometimes (due to the camera angle) it may appear fine, but when rendering, excessive glare starts to appear.

While I understand that materials should always be adjusted, it's tedious to have to constantly manipulate these values, as these values ​​rarely occur in most materials.

Most materials have low reflectance values ​​and are very diffuse, while Centileo starts from the opposite premise: high values ​​and very visible specular highlights.

- The second aspect is HDR lighting.

In both Cycles and Arnold, loading a sky with HDR results in a perfect adjustment of exposure and saturation. However, Centileo tends to oversaturate and overexpose, creating blown-out white areas and an overly colorful (infantilized) background. It's true that there's an "Overrides Environment" option to differentiate between what's visible and what's illuminated, reflected, or refracted... But it lacks the ability to apply sufficient values ​​to the displayed HDR (not the illuminated or reflected portion) to adjust the desired appearance. In this case, a color adjustment modifier for the HDR would be incredibly useful.

- The third section, as you mentioned, is Tonemapping.

- Fourthly.

Image filters that can be applied to the final image, such as Levels or Curves, are sorely missed. Since in cases like having to render 50,000 images, post-production isn't feasible and the final image must be of the highest quality.

In Cinema 4D, these effects can be applied in the "render settings." I haven't tested whether they affect the final render (I imagine they do), but since they aren't available in Centileo's configuration window, most of the time you work with what's visible and avoid using them because they aren't readily available.

And that's essentially what I miss in Centileo. Assuming that other features like expanded parameters for ambient fog, the ability to create volumetric effects, Gaussian splatting integration, advanced proprietary proxies, etc.,

are implementations that will be added over time.

In any case, it's a fantastic renderer, with an undeniable balance of speed, robustness, and quality. Another advantage of Centileo is its IPR refresh rate; there's no other IPR as fast, except for the tests being done with Cycles and DLSS (but those are still in development). This makes things much easier, since the IPR rates of Arnold and Redshift are significantly slower.

https://www.reddit.com/r/blender/comments/1mpqv25/blender_showcases_dlss_upscal­ingdenoising_at/

Best regards.

I've attached screenshots of Cycles when adding an HDR image and loading an FBX file with default values, and another screenshot when loading it in Centileo.

EDIT: I forgot to mention. There's a possibility that the scene won't be resent to the render engine every frame if only the camera is animated. This would significantly reduce render times.

Thanks, Kirgman.

In this type of project, speed is paramount, since thousands of 4K images need to be rendered. I usually only prepare the stadium for that stage and then extract the video from it.

I've worked on advertising projects before, and there, quality is key.

I won't say that Centileo doesn't have the necessary quality to create incredible graphics, but in those cases, I use Arnold Render or Cycles, which allow me to achieve the desired result faster. However, this comes at the cost of speed, as these engines are up to 10 times slower than Centileo.

In any case, Centileo is the perfect partner for a good balance of time and quality.

As for the red furniture theater... It's still on hold.

Thanks again for your comment.

These are projects created by a single person using home-based infrastructure, without any financial resources beyond those available to the average user.

Please be gentle with your criticism, as you may notice errors such as poorly executed animation loops, flickering in the shadows, or shots that lack polish.

Centileo has proven to be extremely robust and reliable.

Regarding the technical specifications of some scenes, 40,000 fans are represented with 8k textures, fabric simulation, and physically simulated flags. Characters can have up to 100,000 polygons each, and HDR up to 32k has been used for ambient lighting. None of this has posed a problem for Centileo, resulting in 1920x1080 images with durations ranging from 27 seconds to 1 minute and 20 seconds, depending on the camera angle.

ANOETA - Real Sociedad

PORTIMAO Circuit

ALIANZ STADIUM Juventus de Turin

SON MOIX - Real Club Deportivo Mallorca

RIAZOR - Deportivo de la Coruña

I'm glad it was helpful. Thanks for the new version.

Good morning, Kirgman.

I've sent you an email with a link to the scene. As usual, I'd appreciate it if you didn't share the scene with anyone.

The selected camera shows the banding error in the footage.

And the second camera has the correct shot to observe the footage change with version 0.718 of Centileo, compared to version 0.717.

I hope this helps.

Thanks.


EDIT:

The geometry is a bit messy (inherited), I've remodeled and cleaned the mesh, in case that could be what's causing the problem, but it persists.

Hello again, kirgman.

The update from 0.717 to 0.718 brings significant changes to some materials.

I'm sorry to hear this.

Thanks in advance.

There is a change with the new version.

It doesn't eliminate the artifact, but it reduces its intensity.

As soon as I have a moment, I'll prepare a basic scene for you to investigate.

Thanks and regards, Kirgman.

Edit:

I've noticed that it might be related to the engine's internal clipping (if such a thing exists), since manipulating camera clipping affects this artifact in the render.

Hello again, kirgman.

Reporting a small bug.

A while ago (when the engine wasn't supported by the RTX 5090) I encountered this shading bug in another stadium model. But with the release of newer versions and support for the RTX 5090, it disappeared.

It hadn't reappeared until now. The thing is, if you look at the attached images, you'll see that it's a sequence of images that moves from one seat to another, and as it moves further away from the concrete wall, the unwanted effect disappears. It's as if it's related to the camera distance, but only with certain materials or objects.

Thanks in advance.

Thanks, Kirgman.

Apparently, everything is fine. The emissive materials are displaying correctly in the materials panel. And after orbiting the camera and constantly moving around the scene for 10 minutes, there hasn't been any crashes.

Thanks again for your promptness and for the thoughtful attention you show on the forum.

Good morning, Kirgman.

A small bug report, which is possibly not caused by the render engine, but rather by the Nvidia drivers. I believe the error lies with the drivers.

The issue is that using version 0.708, Centileo is very stable while using the IPR. However, when switching to version 0.712, in a specific scene, Cinema 4D crashes and the IPR freezes, generating artifacts in the image (similar to when, in images larger than 4096x4096, half the image appeared with lines).

This leads me to believe that it happens when displaying emissive materials in the IPR, but since this is difficult to verify (because sometimes it doesn't fail), I wanted to mention that in the materials panel, the emissive materials appear black, regardless of whether the emission is a color or a texture.

If you revert to version 0.708 and open the scene, rendering the material again displays correctly. This is the bug I'm referring to.

Regards.

Thank you so much for the explanation and the attention you give to my questions.

Clearly, there are processes that I don't fully understand.

And regarding the internal image compression workflow in Cinema 4D, even with a top-of-the-line processor... if it doesn't use parallelization or is outdated code...

Thanks again for your patience.

Thanks for your reply.

I assumed that saving the image was something separate fr om Centileo, but my drives are M.2 SSDs with speeds of 7,500 MB/s, and it doesn't matter which drive I save the scene to.

Understanding that it's always better to save to a drive separate from the operating system or the one wh ere the software (in this case, Cinema 4D) is installed, the time is the same. These are 4000x2000 PNG 16-bit images (between 25 and 35 MB), which shouldn't be a problem for such fast drives. That's why I asked.

However, in Chaos Vantage, I get one image every 2.2 to 3.5 seconds, and it's not affected by saving the image. It's as if it doesn't take into account that it needs to save to start the next frame. I suppose it stays in some buffer and is saved when possible, taking as long as it needs.

Thank you for your time.

Hi again, Kirgman.

Here's a sample video so you can draw your own conclusions. What I see is that it doesn't start the next frame until it saves the current one.

I've noticed in other engines that the save time is independent of the start of the next frame.

https://www.mediafire.com/file/uo1orxgnj43x46h/Kirgman.mp4/file

Best.

Thanks for your reply, Kirgman.

I figured it could be done at the user's request. Centileo is incredibly fast, and I don't think I should demand any more speed, but in my obsession with reducing render times...

In my specific case, I can render up to 50,000 images at 4000x2000. So, even if that step were reduced by 1 second, I'd be saving 50,000 seconds. Almost 14 hours of rendering.

Regards.

Hi Kirgman.

Thanks for the new version. I have a question for you.

I've noticed that whenever there's a frame jump, there's a scene preparation time. And although this time has been greatly reduced, I still notice it.

Does the scene always reload in the engine, regardless of whether there are any animated objects, materials, or lights in the scene?

For example, if only the camera were moving... couldn't the already loaded scene be reused without going through the "Preparing" process?

This would greatly reduce render time for animations without object movement.

If this is already the case, I apologize for the inconvenience and for taking up your time.


Best.

Hello again, Kirgman.

After updating from "Cencitleo 0.706" to "Centileo 0.707," an unwanted effect occurs, as shown in the images.

I'm attaching a sample scene that reproduces the problem.

The thing is, I'm adding "hair" to the head of a character that will later be cloned hundreds of times. To reduce the weight in the render and in the scene itself, I group the hair geometry or several hair models under a null that is hidden from the render and the viewport.

I create an instance of that hair model and set it as a "render instance." I then make it part of a cloner that positions itself on a single vertex of the character's geometry in "multi-instance" mode.

The problem is solved by setting cloning to "instance."

My problem is that I have several projects with hundreds of characters using this technique. And it's impossible to go character by character, modifying the parameter.

Besides, it leaves me wondering under what other circumstances the use of the cloner might affect me.

Best regards.

Thanks, Kingman. You're the best.

Regarding the "Error" in bloom generation in 360 images, it must be intrinsic to it.

I've noticed it also happens in Blender Cycles and After Effects.

I understand the solution to the problem would be complex. It would be something like "taking into account" the union of both ends of the image before applying the bloom effect, so it can be applied to the end of the image that doesn't have the brightness information. If the generation point were at both ends (unless it were perfectly symmetrical), it would always fail, and if there were multiple bloom emission points, the errors would occur at both ends, like a cut line for the effect.

Thank you for your previous response.